home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-pppext-frame-relay-02.txt
< prev
next >
Wrap
Text File
|
1993-10-07
|
15KB
|
608 lines
Network Working Group W A Simpson
Internet Draft Daydreamer
expires in six months October 1993
PPP in Frame Relay
draft-ietf-pppext-frame-relay-02.txt
Status of this Memo
This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ietf-ppp@ucdavis.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Simpson expires in six months [Page i]
DRAFT PPP in Frame Relay October 1993
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of Frame Relay for framing PPP
encapsulated packets.
Applicability
This specification is intended for those implementations which desire
to use facilities which are defined for PPP, such as the Link Control
Protocol, Network-layer Control Protocols, authentication, and
compression. These capabilities require a point-to-point
relationship between peers, and are not designed for multi-point or
multi-access environments.
Simpson expires in six months [Page ii]
DRAFT PPP in Frame Relay October 1993
1. Introduction
Frame Relay [2] is a relative newcomer to the serial link community.
Like X.25, the protocol was designed to provide virtual circuits for
connections between stations attached to the same Frame Relay
network. The improvement over X.25 is that Q.922 is restricted to
delivery of packets, and dispenses with sequencing and flow control,
simplifying the service immensely.
PPP uses ISO 3309 HDLC as a basis for its framing [3].
When Frame Relay is configured as a point-to-point circuit, PPP can
use Frame Relay as a framing mechanism, ignoring its other features.
This is equivalent to the technique used to carry SNAP headers over
Frame Relay [4].
At one time, it had been hoped that PPP HDLC frames and Frame Relay
would co-exist on the same links. Unfortunately, the Q.922 method
for expanding the address from 1 to 2 to 4 octets is not
indistinguishable from the ISO 3309 method, due to the structure of
its Data Link Connection Identifier (DLCI) subfields.
Simpson expires in six months [Page 1]
DRAFT PPP in Frame Relay October 1993
2. Physical Layer Requirements
PPP treats Frame Relay framing as a bit synchronous link. The link
MUST be full-duplex, but MAY be either dedicated (permanent) or
switched.
Interface Format
PPP presents an octet interface to the physical layer. There is
no provision for sub-octets to be supplied or accepted.
Transmission Rate
PPP does not impose any restrictions regarding transmission rate,
other than that of the particular Frame Relay interface.
Control Signals
Implementation of Frame Relay requires the provision of control
signals, which indicate when the link has become connected or
disconnected. These in turn provide the Up and Down events to the
LCP state machine.
Because PPP does not normally require the use of control signals,
the failure of such signals MUST NOT affect correct operation of
PPP. Implications are discussed in [2].
Encoding
The definition of various encodings is the responsibility of the
DTE/DCE equipment in use, and is outside the scope of this
specification.
While PPP will operate without regard to the underlying
representation of the bit stream, Frame Relay requires NRZ
encoding.
3. The Data Link Layer
This specification uses the principles, terminology, and frame
structure described in "Multiprotocol Interconnect over Frame Relay"
[4].
The purpose of this specification is not to document what is already
standardized in [4]. Instead, this document attempts to give a
concise summary and point out specific options and features used by
PPP.
Simpson expires in six months [Page 2]
DRAFT PPP in Frame Relay October 1993
3.1. Frame Format
As described in [4], Q.922 header address and control fields are
combined with the Network Layer Protocol Identifier (NLPID), which
identifies the encapsulation which follows. The fields are
transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q.922 Address | Control | NLPID(0xcf) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and Padding
fields are described in the Point-to-Point Protocol Encapsulation
[1].
3.2. Modification of the Basic Frame
The Link Control Protocol can negotiate modifications to the basic
frame structure. However, modified frames will always be clearly
distinguishable from standard frames.
Address-and-Control-Field-Compression
Because the Address and Control field values are not constant, and
are modified as the frame is transported by the network switching
fabric, Address-and-Control-Field-Compression MUST NOT be
negotiated.
Protocol-Field-Compression
Note that unlike the HDLC framing, the Frame Relay framing does
not align the Information field on a 32-bit boundary. Alignment
to a 32-bit boundary occurs when the NLPID is removed and Protocol
field is compressed to a single octet. When this improves
throughput, Protocol-Field-Compression SHOULD be negotiated.
Simpson expires in six months [Page 3]
DRAFT PPP in Frame Relay October 1993
4. In-Band Protocol Demultiplexing
The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
PPP encapsulation from the other NLPID encapsulations described in
[4].
The joining of the PPP and NLPID number space has an added advantage,
in that the LCP Protocol-Reject can be used to indicate NLPIDs that
are not recognized. This can eliminate "black-holes" that occur when
traffic is not supported.
For those network-layer protocols which have no PPP Protocol
assignment, or which have not yet been implemented under the PPP
encapsulation, or which have not been successfully negotiated by a
PPP NCP, another method of encapsulation defined under [4] SHOULD be
used.
Currently, there are no conflicts between NLPID and PPP Protocol
values. If a future implementation is configured to send a NLPID
value which is the same as a compressed Protocol field, that Protocol
field MUST NOT be sent compressed.
On reception, the first octet following the header is examined. If
the octet is zero, it MUST be assumed that the packet is formatted
according to [4].
PPP encapsulated packets always have a non-zero octet following the
header. If the octet is not the PPP NLPID value (CF hex), and
Protocol-Field-Compression is enabled, and the associated NCP has
been negotiated, then it is expected to be a compressed PPP Protocol
value. Otherwise, it MUST be assumed that the packet is formatted
according to [4].
The Protocol field value 0x00cf is not allowed (reserved) to avoid
ambiguity when Protocol-Field-Compression is enabled. The value MAY
be treated as a PPP Protocol that indicates that another PPP Protocol
packet follows.
Initial LCP packets contain the sequence cf-c0-21 following the
header. When a LCP Configure-Request packet is received and
recognized, the PPP link enters Link Establishment phase.
The accidental connection of a link to feed a multipoint network (or
multicast group) SHOULD result in a misconfiguration indication.
This can be detected by multiple responses to the LCP Configure-
Request with the same Identifier, coming from different framing
addresses. Some implementations might be physically unable to either
log or report such information.
Simpson expires in six months [Page 4]
DRAFT PPP in Frame Relay October 1993
Once PPP has entered the Link Establishment phase, data packets with
other NLPID values MUST NOT be sent, and on receipt such packets MUST
be silently discarded, until the PPP link enters the Network-Layer
Protocol phase.
An implementation which requires PPP configuration (and other PPP
features such as authentication) MAY shut down the link when
configuration fails. Otherwise, when the Configure-Request sender
reaches the Max-Configure limit, it MUST fall back to send only
frames encapsulated according to [4].
5. Out-of-Band signaling
There is no generally agreed method of out-of-band signalling. Until
such a method is universally available, an implementation MUST use
In-Band Protocol Demultiplexing for both Permanent and Switched
Virtual Circuits.
6. Configuration Details
The following Configurations Options are recommended:
Magic Number
Protocol Field Compression
The standard LCP configuration defaults apply to Frame Relay links,
except MRU.
To ensure interoperability with existing Frame Relay implementations,
the initial Maximum-Receive-Unit (MRU) is 1600 octets [4]. This only
affects the minimum required buffer space available for receiving
packets, not the size of packets sent.
The typical network feeding the link is likely to have a MRU of
either 1500, or 2048 or greater. To avoid fragmentation, the
Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
exceed 1500, unless a peer MRU of 2048 or greater is specifically
negotiated.
Some Frame Relay switches are only capable of 262 octet frames. It
is not recommended that anyone deploy or use a switch which is
capable of less than 1600 octet frames. However, PPP implementations
MUST be configurable to limit the size of LCP packets which are sent
to 259 octets (which leaves room for the NLPID and Protocol fields),
until LCP negotiation is complete.
Simpson expires in six months [Page 5]
DRAFT PPP in Frame Relay October 1993
XID negotiation is not required to be supported for links which are
capable of PPP negotiation.
Inverse ARP is not required to be supported for PPP links. That
function is provided by PPP NCP negotiation.
Simpson expires in six months [Page 6]
DRAFT PPP in Frame Relay October 1993
Security Considerations
Security issues are not discussed in this memo.
References
[1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
progress.
[2] International Telegraph and Telephone Consultative Committee,
CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
for Frame Mode Bearer Services", April 1991.
[3] Simpson, W. A., "PPP HDLC Framing", work in progress.
[4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay", RFC 1294, January 1992.
[5] ISO/IEC TR 9577, "Information technology - Telecommunications
and Information exchange between systems - Protocol
Identification in the network layer", 1990 (E) 1990-10-15.
Acknowledgments
This design was inspired by the paper "Parameter Negotiation for the
Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
University of California, Berkeley, 1992, unpublished.
Simpson expires in six months [Page 7]
DRAFT PPP in Frame Relay October 1993
Chair's Address
The working group can be contacted via the current chair:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
EMail: fbaker@acc.com
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
EMail: Bill.Simpson@um.cc.umich.edu
Simpson expires in six months [Page 8]
DRAFT PPP in Frame Relay October 1993
Table of Contents
1. Introduction .......................................... 1
2. Physical Layer Requirements ........................... 2
3. The Data Link Layer ................................... 2
3.1 Frame Format .................................... 3
3.2 Modification of the Basic Frame ................. 3
4. In-Band Protocol Demultiplexing ....................... 4
5. Out-of-Band signaling ................................. 5
6. Configuration Details ................................. 5
SECURITY CONSIDERATIONS ...................................... 7
REFERENCES ................................................... 7
ACKNOWLEDGEMENTS ............................................. 7
CHAIR'S ADDRESS .............................................. 8
AUTHOR'S ADDRESS ............................................. 8
Bill.Simpson@um.cc.umich.edu